IN THE SPECIFICATION: 

Please insert the attached amendments to the 
original specification. 
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At page 2, line 5, change the paragraph to read 
as follows: 

USSN 09/813,667, [[(Docket 041-509-L) ] J 
entitled "THIN CLIENT SIZING TOOL FOR ENTERPRISE SERVER 
FARM SOLUTION CONFIGURATOR" ; 
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At page 2, line 8, change the paragraph to read 
as follows: 

USSN 09/813,671, [[(Docket 041-510-L) ] ] 
entitled "CONFIGURATION INTERVIEW SESSION METHOD FOR THIN 
CLIENT SIZING TOOL"; 
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At page 2, line 11, change the paragraph to 
read as follows: 

USSN 09/813,670, [[(Docket 041-512-L) ] ] 

entitled "SOLUTION GENERATION METHOD FOR THIN CLIENT 
SIZING TOOL"; 
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At page 2, line 13, change the paragraph to 
read as follows: 

USSN 09/813/668, [[(Docket 041-513-L)]] 
entitled "METHOD FOR CALCULATING USER WEIGHTS FOR THIN 
CLIENT SIZING TOOL"; 
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At page 2, line 16, change the paragraph to 
read as follows: 

USSN 09/813,669, [[(Docket 041-514-L) ] ] entitled 
"METHOD FOR CALCULATING MEMORY REQUIREMENTS FOR THIN 
CLIENT SIZING TOOL"; 
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At page 2, line 19, change the paragraph to 
read as follows: 

[[USSN 09/443,926 (Docket 041-475-L) ] ] U.S. 
Patent 6,496,948 entitled "METHOD FOR ESTIMATING THE 
AVAILABILITY OF AN OPERATING SERVER FARM"; 
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At page 2, line 22, change the paragraph to 
read as follows: 

[[USSN 09/474,706 (Docket 041-476-LR) ] ] U.S. 
Patent 6,571,283 entitled "METHOD FOR SERVER FARM 
CONFIGURATION OPTIMIZATION"; 
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At page 2, line 24, change the paragraph to 
read as follows: 

USSN 09/705,441^ [[(Docket 041-479-L) ] ] 

entitled "METHOD FOR SERVER MET AF ARM CONFIGURATION 

OPTIMIZATION'' . 
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At page 7, line 2, change the paragraph to read 
as follows: 

BRIEF DESCRIPTION OF THE DRAWINGS: 

Figs. 1A and IB and 1C show a flow chart 
illustrating methods for configuring and optimizing the 
size of a Metafarm which is tailored to best specify 
utilization for the customer's needs; 
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At page 11, line 22, change the paragraph to 
read as follows: 

13. BASE SOLUTIONS TAB WINDOW (FIG. 23 OF [[DOCKET 041- 
509-L)]] USSN 09/813,667 ; Reports the minimum server 
configuration recommendation (i.e., not including 
additional redundancy or growth considerations) for each 
of the customer Site's server farms. A base solution 
includes the minimum number of servers and 6B RAM 
required with regard to the Operating system, # 
processors and MHz available for each server type 
supported by Unisys. 
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At page 14, lines 3-4 , change the paragraph to 
read as follows: 

24. DISK CAPACITY TAB WINDOW (FIG. 27 OF [[DOCKET 041- 
509-L)]] USSN 09/813,667 ; Reports on the disk capacity 
requirements determined by the interview session input 
and solution generation algorithms for each of the 
customer Site's Server Farms. 
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At page 16, lines 7-8 , change the paragraph to 
read as follows: 

36. NETWORK CAPACITY TAB WINDOW (FIG* 26 OF [ [DOCKET 
041-509-L)]] USSN 09/813,667 ; This is called Network 
Utilization now; reports on the estimated network 
activity measured in Kbps for each of the customer Site's 
Server Farms* 
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At page 17, lines 1-2, change the paragraph to 
read as follows: 

39. OPTIONAL SOFTWARE TAB WINDOW (FIG. 25 OF [[DOCKET 
041-509-L)] ] USSN 09/813/667 ; Reports on the additional 
features/capabilities entered in the interview session 
regarding the customer's profile for each of the Site's 
Server Farms. Optional software requirements include such 
categories as Client Connection Methods, Enhancements, 
Environment support, Multimedia capabilities. Display 
characteristics. Protocol support, and Server 
Enhancements • 
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At bottom of page 22 and continuing to top of 
page 23, lines 1-7, change the paragraph to read as 
follows: 

Fig. 3 is an example of a particular type of 
configuration known as a Server Metafarm 8. The Metafarm 8 
may include a number of Server Farms designated as 10A, 
10B, IOC . . . 10K. Each of the Server Farms will be seen 
to have a disk database server 12A, 12B . . . 12K, and a 
series of application programs with hardware servers. For 
example, Server Farm 10A will have a disk database server 
12A, which is attached to a series of application programs 
10P, 20P, and [ [PAN] ] AN. Each of these programs is 
associated respectively with a particular hardware server 
Al, A2 and [ [N] ] AN. 
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At page 23, line 31, change the paragraph to 
read as follows: 

In order to help a designer or supplier support 
a customer to develop an optimum configuration for their 
large user group (or Metaf arm) , which can be configured to 
optimize the services to be provided to the customer or 
user, a very specific set of information referred to as 
the "Customer Profile" is first developed and placed in a 
Configuration Session Database 50. This Customer Profile 
development was described in co-pending USSN 09/813,671, 
[[(Docket 041-510-L) ] ] entitled "CONFIGURATION INTERVIEW 
SESSION METHOD FOR THIN CLIENT SIZING TOOL" and is 
incorporated by reference herein* 
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At page 24, lines 16-21, change the paragraph 
to read as follows: 

In conjunction with the interview process, the 
option is available to a customer to obtain assistance in 
subdividing their large site into reasonably- sized Server 
Farms. The present method can be used during or prior to 
the interview process to systematically determine the 
most efficient subdivision recommendation for the 
customer. Once this subdivision is determined, the 
configuration interview session is then resumed for 
further development of the user and application type 
attributes of the customer's users that are pertinent to 
configuration sizing. Once this information has been 
developed, it is placed in the Configuration Session 
Database (as seen in the co-pending application, USSN 
09/813,671 , [[Docket 041-510-L] ] . The present method 
will be seen in Figs. 1A and IB and 1C and described 
herein together with some specific numbers and parameters 
which will further illustrate how the particular 
algorithm is developed. Here, the series of steps in the 
flowchart of Figs. 1A, IB, 1C, will be designated by 
various markers, such as CI, C2, C3, etc., through C20. 
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At page 24, lines 25-26, change the paragraph 
to read as follows: 

Metafarm sizing for configuration optimization 
in Fig. 1A, is entered from the Configuration Interview 
Session described in co-pending USSN 09/813/671. [ [, ] 3 
[[(Docket 041-510-L) .]] Initial default values for the 
required Input step (Cl) are programmatically entered 
initially by the configurator as seen in Table I, which 
will illustrate a typical example. 
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At page 26, line 11, change the paragraph to 
read as follows: 

The User weight factor is also gleaned from the Server 
Info Database 20, Fig. [[3]] 2, on a server basis to 
determine how a user compares to a benchmark user. A 
Heavy user is customarily considered the same weighting 
factor as a benchmark user therefore making its factor = 
1. A "Light" user, however, would be considered to use 
50% of the system resources as a benchmark user. The 
following Table II is a mapping for customary user weight 
factors with respect to a typical benchmark user. 
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At page 27, add a new line 6, to read as 

follows: 

Redundant Servers per Farm 
[EQ2] = <Servers per Farm>*RF 
= 358 * 0.25 

a 89 Redundant Servers per Farm 

[where * « a multiplication sign] 

Then C6 continues via connecting marker CW over to step 
C7 on Fig. IB. 
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At page 28, line 23, change the paragraph to 
read as follows: 

3. Server Benchmark testing results for the 
preferred Server's Mean Time To Failure 
(MTTF) = 1200 hours (which is stored in the 
Server Info Database of Fig. [[3]] 2, element 

20) . 
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At page 29, line 21, change the paragraph to 
read as follows : 

The #Farms (number of Farms) is incremented 
from 3 to 4 at step (CIO) and since the number of Farms 
is still not greater than 100, "NO" is answered at step 
(Cll), then the next updated recommendation is calculated 
at step (C5) thus dividing the Users into farms via steps 
(C5) to (C8). If the Estimated Availability Level at 
step (C9) meets or exceeds the Availability Goal (YES) , 
the Estimated Availability Level is stored in the Choices 
array at the index #Recommendations step (C9Y) • The 
#Recommendations (C9Y2) and incremental #Farms (CIO) are 
both incremented by 1. This loop sequence continues 
until #Farms is incremented to be more than 100 at which 
time ^YES" is the answer at step (Cll) to ^Is 
#Farms>100?" (Cll) . 
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At page 29, line 25, add a new sentence to read 
as follows: 

The # Farms (number of Farms) is Incremented 
from 3 to 4 at step (CIO) and since the number of Farms 
is still not greater than 100, "NO" is answered at step 
(Cll), then the next updated recommendation is calculated 
at step (C5) thus dividing the Users into farms via steps 
(C5) to (C8). If the Estimated Availability Level at 
step (C9) meets or exceeds the Availability Goal (YES), 
the Estimated Availability Level is stored in the Choices 
array at the index #Recommendations step (C9Y) . The 
#Recommendations (C9Y2) and #Farms (CIO) are both 
incremented by 1. This loop sequence continues until 
#Farms is incremented to be more than 100 at which time 
"YES" is the answer at step (Cll) to "Is #Farms>100?" 
(Cll) . The "YES" leg of Cll continues via marker CY over 
to Fig, 1C. The "NO" leg of Cll continues via marker C2 
over to Fig. 1A> 
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At page 31, line 18, change the paragraph to 
read as follows: 

After the calculations are redone using the new 
Redundancy Factor, the recommendation choices have been 
narrowed down to a more optimal configuration 
recommendation. At this point, the Choices array ( C14Y) 
will have the following recommendation entries shown in 
Table IV: 
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At page 32, 1 ine 1 0, change the paragraph to 
read as follows: 

The next decision block at step (C12) is 
required to determine "Is #Recommendations>0?" (C12) 
indicating whether or not some recommendations exist that 
will meet the customer's criteria. If the answer is 
n Yes", the redundancy factor increment variable Rfinc, 
which is currently -5%, is checked and asked *ls RFinc 1%" 
(C12Y) to which the answer is *N0" and the RFinc variable 
is reset to -5% at (C12YN) . And the redundancy factor, RF 
is incremented by RFinc (C13) resulting in the redundancy 
factor being decremented [[form]] from 20% to 15%^ 
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At page 34, line 13, change the paragraph to 
read as follows: 

Now at step (C12, Fig. [[IB]] 1C) , the decision 
block question "Is the #Recommendations greater than 0?" 
is answered "YES", as well as the question "Is your RF 
increment 1%?* step (C12Y) to which a "YES" indicates 
that the optimum redundancy factor has been found. The 
information in the Choices array step (C14Y) is then 
displayed in the Metafarm Sizer Server Farm Subdivision 
Recommendations grid on the User's PC screen at step 
(C15). The column of the recommendation that has the 
least number of total servers is highlighted at step 
(C16) to indicate the sizer' s best recommendation (C16) . 
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At page 35, lines 27-30, and continuing through 
page 36, lines 1-2, change the paragraph to read as 
follows: 

2. Selecting a recommendation column via step C18 
in the Sizer's Server Farm Subdivision 
Recommendation Grid and returning the #Farms 
and Users per Farm [[(C18)]] (C18A) for use in 
the Interview Session as shown in co-pending 
USSN 09/813,671 , [[(Docket 041-510-L)]] for 
information for the methods used on the 
Configurator Interview Session) . The algorithm 
is then exited (C20) . 
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At bottom of page 35 through top of page 36, 
lines 1-2, change the paragraph to read as follows: 

2. Selecting a recommendation column in the 
Sizer's Server Farm Subdivision 
Recommendation Grid and returning the 
#Farms and Users per Farm (C18) for use in 
the Interview Session as shown in co- 
pending USSN 09/813,671 , [[(Docket 041- 
510 -L) ] ] for information for the methods 
used on the Configurator Interview 
Session) . The algorithm is then exited 
(C20) . 
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IN THE CLAIMS : 

Please amend claims 1-7, as indicated. 
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1. (Currently Amended) In a Thin Client Sizing Tool, a 
method for developing a Metafarm having an optimal number 
of Server Farms to provide recommended configurations 
meeting certain specified parameters, wherein a number of 
factors are established which include: (i) the total 
number of users who will be using the Metafarm; (ii) an 
Availability goal which indicates the percentage of time 
that the systems and applications in each Server Farm 
will be accessible to all the users involved; (iii) 
assigning a user weight volume to each type of user to 
indicate estimated average usage or light, medium, heavy 
or super heavy; (iv) calculating the number of servers to 
be assigned to each Server Farm and which will fulfill 
the said Availability goal; (v) calculating the number of 
redundant servers per Server Farm needed to provide 
maximum performance over and above the average nominal 
performance while still fulfilling said Availability 
goal; (vi) seeking to find the minimum number of Server 
Farms which still provide an optimum Redundancy Factor of 
extra servers which will still fulfill the desired 
Availability goal, comprising the steps of: 

(a) delivering input data on the total number 
of users to be serviced, the Availability goal 
to be achieved, the User-Weight utilization 
factors involved, and the preferred Server 
types to be used; 

(b) sequencing a series of calculations to 
determine the number of Servers per Farm and 
the number of redundant Servers per Farm which 
match or exceed the said Availability goal; 
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(c) displaying a set of recommendations which 
show the minimum number of Server Farms which 
have the optimum redundancy factor and meet the 
values needed for the Availability goal. 
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2. (Currently Amended) The method of claim 1 [[2]] 
wherein data on Benchmark operational parameters are 
consulted on a specific type of server to establish the 
maximum number of users which can be supported by said 
chosen specific type of server, and wherein step (b) 
includes the steps of: 

(bl) retrieving a Benchmark parameter 

which indicates the maximum number of 

users which can be serviced by a chosen 
Server type; 

(b2) calculating a preliminary number of 

such chosen Servers which will constitute 
a Server Farm; 
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3. (Currently Amended) The method of claim 2 wherein a 
desired Redundancy Factor is used to add enough extra 
servers, designated as a number of redundant servers per 
farm, to enable maximal user usage over nominal user usage 
and wherein an estimated Availability Level is set for 
each chosen Server Farm, and wherein step (b2) includes 
the steps of: 

(b3) calculating the number of redundant 
Servers per Farm according to a 
preliminary set percentage parameter for 
the Redundancy Factor; 

(b4) calculating the estimated 

Availability Level for the Server Farm 
chosen. 
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4. (Currently Amended) The method of claim 3 wherein a 
desired Availability Level goal of a certain maximum 



downtime value is ..checked to see if it meets said 
Availability Level goal according to the number of Server 
Farms first estimated and the number of server s-per- farm 
first estimated, and the number of redundant servers-per- 
farm first estimated/ and which includes the steps of: 

(b5) if step (b4) Availability Level does 
not meet or exceed the Availability Level 
goal, then initiate a sequential loop by 
either incrementing or decrementing the 
number of Server Farms to re-calculate the 
number of Servers per Farm and number of 
redundant Servers per Farm which meet or 
exceed the Availability Level goal 
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5. (Currently Amended) The method of claim 3 wherein there 
is acc«™™™^ted a Redundancy Factor indicating the 
possible number of extra users which can be accommodated 
in a Server Farm which is added to the nominal number of 
user s-per- server without exceeding the maximum allowable 
user s-per- server set by benchmarking data, 

and wherein correlation is made between the 
number of user s-per- Server Farm, the number of servers and 
the estimated Availability Level for each Server Farm and 
wherein there is established the total number of servers 
in the entire Metafarm, and which includes the steps of: 

(b5) decrementing the Redundancy Factor 
until no acceptable recommendations are 
available; 

(b6) incrementing the Redundancy Factor in 
steps of 1% to find the optimum Redundancy 
Factor; 

(b7) storing configuration recommendations 
in an array indicating output displays of 
the number of Servers correlated to the 
number of Users per Farm with the 
estimated Availability Level, estimated 
yearly downtime, number of redundant 
Servers in the Metafarm and the total 
number of Servers in the Metafarm* 
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6. (Currently Amended) In a Thin Client Sizing tool, a 
method for optimizing the number of Server Farms to 
provide the most efficient recommended configurations 
which provide a desired Availability Level goal and 
Redundancy Factor, wherein data is accumulated as to the 
number of Users to be involved, the Availability goal of 
maximum downtime permitted, and the usage weight load by 
each type of user; the number of servers to be utilized 
in each Farm, plus the number of redundant servers to be 
placed in each Server Farm to allow performance service 
beyond the nominal usage; utilizing an experienced 
benchmark value for types of servers involved to ensure 
that the number of server s-per- farm does not exceed the 
appropriate benchmark value for the type of server 
involved; providing a calculated Availability Level for 
the maximum allowable downtime which meets the downtime 
goal for Availability Level; reporting out a number of 
output recommendations which correlates sets of 
parameters which link the number of farms with the number 
of user s-per- farm with the Estimated Availability, with 
the Estimated Downtime, with the number of Redundant 
Servers, and with the Total Number of Servers in order to 
select that set of parametric criteria which best fulfill 
a selected customer's requirements, comprising the steps 
of: 

(a) inputting of data to indicate the number 
of users involved, the Availability goals, the 
user-weight factors, and preferred server 
types; 

(b) calculating the number of Servers per Farm 
to be utilized; 

38 
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(c) calculating the number of redundant 
Servers to be placed in each Server Farm; 

(d) using a benchmark to check if the number 
of Servers per Farm from steps (b) and (c) 
exceed the benchmark values for the Servers 
involved; 

(e) if step (d) indicates that the number of 
Servers per Farm does not exceed the benchmark 
value, then calculating the estimated 
Availability Level of the Server Farm; 

(f) checking to see that the said calculated 
Availability Level meets or exceeds the 
Availability Level goal; 

(g) if the Availability Level goal is not met 
or exceeded, then incrementing the number of 
Server Farms by w l"; 

(h) checking to see if the number of Server 
Farms is greater than 100 or not greater than 
100; 

(i) if the number of Server Farms is less than 
100, then requesting through steps (b) , (c), 
(d), (e), (f), (g), and (h) until step (h) 
indicates that the number of Server Farms is 
greater than 100; 

(j) checking to see that the number of output 
recommendations is greater than "0"; 
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(k) decrementing the Redundancy Factor in 
steps of 5% until no acceptable recommendations 
are available; 

(1) incrementing the Redundancy Factor in 
steps of 1% to develop a set of recommendations 
which minimize the number of Server Farms while 
still supporting the number of users required 
and still meeting the Availability Level goal. 
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7. (Currently Amended) A Thin Client Sizing Tool system for 
configuring a Metafarm consisting of multiple Server Farms which 
provides the optimum size and Availability Level goals for a 
specified customer profile wherein data is stored which specifies 
the number of servers basically required to service any given 
number of users; and algorithmic program means for establishing 
the optimum number of servers -per- farm and optimum number of 
red^^^t servers -per- farm which will provide the most cost- 
efficient service for the customer's special requirement; 
selective choices of Redundancy Factor values which will satisfy 
a customer's prescribed Availability Level goal as to the maximum 
allowable downtime, comprising: 

(a) customer profile data means stored in a customer 
database; 

(b) benchmark information means stored in a benchmark 
database indicating the number of Servers required to 
service a given number of users; 

(c) program means for calculating the optimum number 
of Servers per Farm and the optimum number of redundant 
Servers per Farm; 

(d) lopp sequencing means for configuring different 
numbers of Servers per Farm with different values of 
the Redundancy Factor to display parameters which meet 
or exceed a prescribed Availability Level goal. 
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REMARKS 



In response to the Examiner's Office Action of July 29, 
2004, Applicants have taken under review the Examiner's 
statements and considerations on this case. 

In regard to the drawings, the Examiner has suggested 
that the reference characters C7 through C20 have not been 
included in the description of Figs. 1A, IB and 1C. On reviewing 
pages 25-36 of the text of the specification, it will be noted 
that in actual fact, each of the various factors have been 
covered, except for step C18A, which now has been added by 
amendment to the specification. 

Further, in regard to Examiner's comment about the 
marker notations CZ and CW, which appear in the drawings of 
Fig. 1A, IB and 1C, these marker designations have now been put 
into the amended text of the specification. 

The Examiner has rejected claims 1-7 for indef initeness 
and lack of antecedent basis under 35 USC 112, second paragraph, 
with Examiner indicating the various phrases which he considers 
lacks the antecedent basis. Accordingly, Applicants have now 
amended these claims in order to provide antecedents for all the 
referenced phrases which Examiner indicated as lacking in 
antecedent basis. Thus, there should no longer be any objection 
under 35 USC Article 112 in regard to these claims. 

The Examiner has re j ec t ed claims 1-7 under 3 5 USC 
102(e) as being "anticipated" by the Blumenau reference, U.S. 
Patent 6,665,714. At this juncture, Applicants would hereby 
traverse the Examiner's conclusions as to anticipation on these 
claims. Applicants will hereinbelow address various aspects and 
clauses of Applicants' claims with regard to the citations that 
Examiner has made in the Blumenau reference. 

REGARDING APPLICANTS' CLAIM 1 ; In Applicants 1 claim 1(a) 

regarding delivering input data to the total number of users 

to be serviced, the availability goal to be achieved, the User- 
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Weight utilization factors and the preferred server types to be 

used the Examiner has cited the Blumenau reference column 4, 

lines 40-47* 

Here, Blumenau references his Fig. 16 to illustrate a 
method of graphically representing how data is stored 
in a storage system that can be provided by a Graphical 
User Interface — wherein Fig. 16 identifies various 
numbers of "volumes" and indicates the owners thereof. 

Thus, it can be seen that certainly Blumenau 
does not teach any information about a Server 
Farm and the total number of users to be 
serviced, the availability goals to be 
achieved, the User-Weight utilization factors 
involved and the preferred server types. 
Therefore, it is not permissible to say that 
Blumenau can teach claim 1(a) of Applicants 1 . 



REGARDING APPLICANTS' CLAIM Kb) ; This involves sequencing a 
series of calculations to determine the number of Servers per 
Farm and the number of Redundant Servers per Farm which match or 
exceed the availability goal: 

Here, the Examiner cites Blumenau column 6, line 35-67: 
This involves a data management aspect of Blumenau 
which configures volumes of data at the storage system 
20 according to the identity of the host devices 
coupled to the storage system. The configuration data 
is used to manage the allocation of volumes to 
different hosts which may be provided by a system 
administrator of the network. The system administrator 
tracks the host devices that are coupled to the network 
and the available volumes at the storage system. As a 
new host device enters the network, the system 
administrator allocates storage volumes to the host. 
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Now, it can be seen that there is no teaching 
in Blumenau of sequencing a series of 
calculations to determine the appropriate 
number of Servers per Farm and the number of 
Redundant Servers per Farm* 

Examiner then cites Blumenau column 21, lines 45-60, 
regarding Applicants 1 claim Kb): — Here, Blumenau 
discusses a utility being provided to give additional 
identification information pertaining to the host and 
host pairs that are logged into a storage system. An 
alias can be used to view and manage the host pair and 
configure storage volume assignments therefore. The 
utility may be implemented in software that executes on 
the CPU of a host processor to include this additional 
information in the history table 1269 of the 
configuration database. 

Again, it will be seen that Blumenau does not 
indicate a series of calculations to 
determine the number of Servers per Farm, and 
the number of Redundant Servers per Farm. 

Examiner cites column 26, lines 1-20 regarding 
Applicants 1 claim 1(b): — Here Blumenau discusses a shared 
assigned storage volume icon 1540 which represents a storage 
volume in a storage system that has been assigned to more than 
one host processor /HBA pair in the configuration database 1232 of 
the storage system. 

Here, a discussion of a configuration 
database related to assignments of storage 
volumes has nothing to do with the teaching 
of determining the number of Servers per Farm 
and the number of redundant Servers per Farm. 
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IN REGARD TO APPLICANTS' CLAIM 1(C); Examiner has cited Blumenau 
column 17, lines 45-67: — Here, Blumenau discusses a user 
interface for a system administrator. The user interface 
communicates with a configuration database of a storage system to 
enable a user or another application program to view and manage 
the availability and assignment of data storage volumes to 
different hosts in a storage network. . . . A Graphical User 
Interface is provided with which a user can graphically view the 
availability and assignment of data storage volumes to different 
hosts in a storage network* 

It is to be noted that the Blumenau reference 
does not teach Applicants 1 clause (c) for 
displaying a set of recommendations which 
show the minimum number of Server Farms which 
have the optimum redundancy factor and meet 
the values for the availability goal. 

Then, Examiner cites column 18, lines 1-25, regarding 
Applicants' claim 1(c): — this aspect of Blumenau involves a 
command line interface provided that can be used to query the 
availability and assignment of data storage volumes to different 
hosts in the network. The command line interface allows a user or 
another application program to generate reports illustrating the 
topology of a storage network. 

Here again, there is no teaching of 
displaying recommendations for the minimum 
number of Server Farms which have the optimum 
redundancy factor. 

In Applicants' claim 1(c), Examiner has cited Blumenau 

column 25, lines 10-67: Here, Blumenau discusses a GUI 

Management Window 1400 which displays devices, such as host 
processors, storage systems, host bus adapters, and storage 
system adapters, in a storage area network with each device being 
represented by an easily recognizable icon ... an administrator 
host permits the allocation of volumes and the modification of 
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how devices are connected in the storage network to be managed 
from a central control station or host processor. 

There is nothing here in these generalized 
statements of Blumenau which would enable a 
set of recommendations to show the minimum 
number of Server Farms which have the optimum 
redundancy factor. 

Examiner has cited Blumenau column 30, lines 15-20 in 
regard to Applicants 1 claim 1(c): — Here, Blumenau indicates a 
report option may be used to generate information detailing the 
configuration of a storage network or the configuration of a 
particular device or volume, and this information can be either 
displayed or written to a file. 

Note that Blumenau is involved with the 
problem of assigning a particular volume to a 
particular device , and only talks in 
generalized terms here, so that there is no 
possible teaching regarding recommending the 
minimum number of Server Farms which have the 
optimum redundancy factor and which meet the 
availability goals. 

Now, likewise, claims 2-5 which are dependent on claim 
1 will be seen to be completely dif f erentiative in Applicants 1 
system from any of the teachings indicated by the Examiner in the 
Blumenau reference. 
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IN REGARD TO APPLICANTS' CLAIM 6 AND CLAUSES (a). (b),(c), 
(d),(e), (f). , . THROUGH CLAUSES H), (k) , (1) : Here, it should 
be indicated that none of the columns and lines of Blumenau which 
have been cited by the Examiner can possibly be imputed to handle 
the various factors as the number of users involved, the 
preferred server types, the number of Servers per Farm, the 
number of Redundant Servers, the use of benchmark data meeting 
the availability level goal, and the method of decrementing or 
incrementing the redundancy factor to develop a set of 
recommendations which minimizes the number of Server Farms, while 
still meeting the requirements of the number of users and the 
availability level goals. 



IN REGARD TO APPLICANTS' CLAIM 7, CLAUSES (a), (b).(c), (d) ; The 
Examiner has cited several columns of the Blumenau reference, and 
herein Applicants will discuss several aspects of the clauses 
involved herein. 

In Applicants' claim 7(b), the Examiner has cited 
Blumenau column 2, lines 1-15: Here, it is seen that Blumenau 
indicates a storage system including at least one storage device, 
apportioned into a plurality of volumes, a configuration table to 
store configuration data identifying which of a plurality of 
devices coupled to the storage system are authorized to access 
each of the plurality of volumes, and a filter to 
selectively forward to the at least one storage device requests 
for access to the plurality of volumes. . * . 

Now, looking at Applicants' claim 7(b), which 
involves benchmark information means stored 
in a benchmark database indicating the number 
of servers required to service a given number 

of users: Here, it can be seen that 

Blumenau statements in column 2, lines 1-15 
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certainly do not involve servers, they do not 
involve benchmark information or a benchmark 
database, or means to indicate the number of 
servers required to service a given number of 
users. Therefore, it can be seen that this 
Blumenau reference cannot teach Applicants' 
claim 7, clause (b) . 

Then also, the Examiner has cited Blumenau column 30, 
lines 15-20, in respect to Applicants 1 claim 7, clause 

(b), where Blumenau indicates a report option may 

be used to generate information detailing the 
configuration of the storage network or the 
configuration of a particular device or volume, and 
this information can be either displayed or written to 
a file. 

Again, this rudimentary statement and 
information by Blumenau has no relationship 
to the use of benchmark information from a 
benchmark database to help find the number of 
servers required to service a given number of 
users . 

In regard to Applicants 1 claim 7(c), Examiner has cited 
Blumenau column 6, lines 35-67: - — Basically here, Blumenau 
discusses a data management aspect which configures volumes of 
data at the storage system 20 according to the identity of the 
host devices coupled to the storage system. The configuration 
data is used to manage the allocation of volumes to different 
hosts, and this may be handled by a system administrator of the 
network. • • . The number of volumes allocated to the host may 
be based on a requested number of volumes or alternatively, may 
be based on historical data requirements of the host. • • . 

As can be seen here in Applicants 1 claim 7, 
clause (c), Blumenau provides no teaching, 
instruction or usage which involves program 
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means for calculating the optimum number of 
Servers per Farm and the optimum number of 
Redundant Servers per Farm. 

Likewise, column 21 of Blumenau lines 45-60, and column 
6, lines 1-20, can also be seen not to teach any such operation, 
as is indicated in Applicants 1 clause (c) of claim 7. 

In regard to Applicants 1 claim 7(d), Examiner has cited 
Blumenau column 6, lines 1-41: — This Blumenau aspect basically 
involves one or more hosts which may be coupled to one or more 
storage systems using a network, with requests and responses 
being forwarded to and from the "storage systems" over the 
network according to the protocol of the network* 

Here, Blumenau does not indicate, show, or 
teach any aspect of Applicants 1 clause (d) 
involving loop sequencing means for 
configuring different numbers of Servers per 
Farm with different values of the redundancy 
factor in order to display parameters which 
meet or exceed a prescribed availability 
level goal. 

Further, regarding Applicants 1 clause 7(d), Examiner 
cites Blumenau column 22, lines 1-30: — where Blumenau states: - 
- In a loop storage network topology, similar information may be 
obtained by querying each device in the loop and examining the 
Wns of each device in a similar manner. ... Here, there is 
involved a storage network that includes a configuration database 
that facilitates shared access to "storage" resources, such as a 
configuration database 1232 (Fig. 12). 

Other than mentioning a loop sequence means, 
it is seen that this does not relate to 
configuring different numbers of "Servers" 
per Farm with different values of the 
redundancy factor to display parameters which 
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meet or exceed a prescribed availability 
level goal. Thus, there is no teaching which 
would obviate claim 7 (d) . 



To summarize the overall situation, just because the 
Blumenau patent indicates the use of processors coupled to a 
storage system over a network, it is in no way indicative or of 
teaching that it can teach and resolve the methods for optimizing 
a Server Farm. It should be noted that Applicants 1 system 
involves a thin client sizing tool having a method for developing 
a Metafarm having an optimal number of Server Farms to provide 
the proper configuration for multiple Server Farms and for 
certain specified parameters required for the system. No such 
teaching or capability will be found in the Blumenau reference. 

In view of the above discussion, and in view of the 
factors shown which indicate that Blumenau cannot possibly teach 
Applicants 1 system and method for designing an optimized Server 
Farm or Metafarm to meet the needs of a specified customer, (as 
determined by the customer's profile), it can be readily seen 
that Applicants have contributed a valuable methodology to the 
technology of developing Server Farms to suit each particular 
individual customer involved. 

As a result, it is now considered that Applicants 1 
system should be viewed as a whole in its entirety, which does 
not fall under the generalized statements made by Blumenau in 
regard to identifying storage volumes — in fact, quite a 
different series of problems are involved in Applicants 1 system 
which are not attacked by the Blumenau reference, and as a 
result, it is contended that Applicants' claims, when viewed as a 
whole in their entirety, do provide a substantive inventive 
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entity for which Applicants pray that Examiner will provide a 
timely Notice of Allowance therefor. 

Respectfully submitted, 
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